This application relates to communication systems, and more particularly to communication systems having user equipment configurable with different software components.
Today, several actors are involved in managing the software in a user equipment (UE), such as a mobile telephone or other communication device in a radio communication system. The software can be applications, services, and modules, including the operating system (OS), stored in and used by the UE. The device manufacturer completes a working software release in the UE at the time the device is manufactured. Later on, an end user may download to the UE software applications etc. from different sources via, for example, the Internet. The UE manufacturer, the system operator, and/or an authorized third party, depending on business agreements, may also remotely update part or all of the working software release.
After such an update, some of the UE's applications may no longer work because there exist dependencies between applications in devices such as UEs. The end user may also download an application that depends on a specific version of a software module that is not or is no longer present in the device, and then such an application will most likely not run. To conserve the limited memory resources available to most UEs, multiple versions of a module are typically not retained in UE memory.
The Open Mobile Alliance (OMA) has developed specifications for Device Management (DM) in communication devices, and versions 1.1.2 and 1.2 of those specifications define a protocol for managing configuration, data, and settings in communication devices. OMA standards and other information are available at http://www.openmobilealliance.org.
DM relates to management of UE configuration and other Management Objects (MOs) of UEs from the point of view of different DM Authorities, and includes, but is not restricted to, setting initial configuration information in UEs, subsequent updates of persistent information in UEs, retrieval of management information from UEs, and processing events and alarms generated by UEs. Using such DM, third parties can configure UEs on behalf of end users. A third party, such as a network operator, service provider, and corporate information management department, can remotely set parameters, troubleshoot terminals, and install or upgrade software. For example, an MO may be written according to SyncML, which is a mark-up language specification of an XML-based representation protocol, synchronization protocol, and DM protocol, transport bindings for the protocols, and a device description framework for DM.
A UE can, for example, use a Connectivity MO for application-independent settings to connect to a network, such as a wireless application protocol (WAP) network. A Connectivity MO for such a network would provide connectivity information that relates to the parameters and means needed to access the WAP infrastructure, including network bearers, protocols, Network Access Point (NAP) addresses, and proxy addresses. Connectivity MOs are described in “DM Connectivity Management Objects”, http://www.openmobilealliance.org/ftp/Public_documents/TP/ Permanent_documents/OMA-WID—01 23-ConnectivityMO-V1—0-20051004-A.zip, OMA (Oct. 7, 2005).
A WAP proxy is an endpoint for the wireless transport protocol (WTP), the wireless session protocol (WSP), and the wireless transport layer security (WTLS) protocol, as well as a proxy that is able to access WAP content. A WAP proxy can have functionality such as that of, for example, a wireless session protocol (WSP) proxy or a wireless telephony application (WTA) proxy. A physical proxy is a specific address with proxy functionality, e.g., an internet protocol (IP) address plus port for an IP-accessible proxy, and a short message entity (SME)-address plus port for a proxy accessible via the short message service (SMS). A logical proxy is a set of physical proxies that may share the same WSP and WTLS context (shared session identification value space).
According to OMA specifications, a Connectivity MO enabler handles management of wireless data connectivity by specifying a set of DM object schema that may be exposed by a DM Client and targeted by a DM Server. The object schema have three parts: a top level management object that is bearer-neutral; a set of bearer-specific parameters; and a sub-tree for exposing vendor-specific parameters. Connectivity parameters bootstrapped using Client Provisioning (CP) can be subsequently addressed and managed through the DM Server, which can add new proxies and NAPs using a standardized DM package. Provisioning is the process by which a client, such as a WAP client in a device, is configured, and generally covers both over the air (OTA) provisioning and other provisioning, e.g., by a subscriber identity module (SIM) card.
As depicted in FIG. 1, a DM Management Authority (MA) 102 issues a request to a DM Server 104, for example, to provision data connectivity parameters in one or more devices. The DM Server 104 sends a Server-initiated Notification to the UE 106, which establishes a DM Session with the DM Server 104, which queries the UE for current settings (which may include device-specific extensions). The DM Server 104 sends DM commands to adjust the UE's configuration to conform to requirements established by the DM MA 102. The UE 106 and DM Server 104 end their DM Session, and the UE is able to access network data services using the configured connectivity parameters. The DM MA or the DM Server may store the connectivity parameters on a “smart card” or the like so that the UE can use them when the UE is consuming the parameters.
Approaches to updating the firmware in a UE exist in OMA. For example, version 1.0 of a candidate enabler for a Firmware Update MO specifies MO(s) and their necessary behavior to support the updating of firmware in mobile devices. It will be understood that “firmware” is computer programming instructions that are usually used from a read-only memory (ROM) and that “software” is computer programming instructions that are usually used from a read/write memory. OMA's candidate Firmware Update MO uses the OMA DM enabler and supports alternate download mechanisms (such as OMA Download Over the Air (OTA)). This represents the interface between a DM Client in the UE and a DM Server required to manage the update of a mobile device's firmware.
OMA also has a Software Component Management Object (SCOMO) work item under development. With DM and SCOMO, it may eventually be possible remotely to install all needed software that an MA has decided is a full working set of applications.
Nevertheless, DM and SCOMO cannot take into account dependencies between applications, e.g., applications that an end user may download. There is not a standardized way for the UE to notify or request an installation of a software component that is needed by an application.